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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides the protocol details for the Flexible Alerting supplementary service in the IP 
Multimedia (IM) Core Network (CN) subsystem based on the requirements from 3GPP TS 22.173 [2]. 

Flexible Alerting (FA) causes a call to a pilot identity to branch the call into several legs to alert several termination 
addresses (group members) simultaneously. The first leg to be answered is connected to the calling party. The other call 
legs are abandoned. 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to 
support the FA supplementary service. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 22.173: "IP Multimedia Core Network Subsystem (IMS) Multimedia Telephony Service 

and supplementary services; Stage 1". 

[3] 3GPP TS 23.002: "Network architecture". 

[4] 3GPP TS 24.238: "Session Initiation Protocol (SIP) based user configuration; Stage 3". 

[5] 3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[6] 3GPP TS 24.623: "Extensible Markup Language (XML) Configuration Access Protocol (XCAP) 

over the Ut interface for Manipulating Simulation Services". 

[7] 3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and 

message contents". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 
3GPPTR 21.905 [1]. 
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3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 



AS 


Application Server 


CS 


Circuit Switched 


CN 


Core Network 


FA 


Flexible Alerting 


IP 


Internet Protocol 


IM 


IP Multimedia 


MMTEL 


Multimedia Telephony 



Flexible Alerting (FA) 



4.1 Introduction 

Flexible Alerting (FA) causes a call to a Pilot Identity to branch the call into several legs to alert several termination 
addresses (group members) simultaneously. Additional calls may be delivered to the FA Pilot Identity at any time. The 
first leg to be answered is connected to the calling party. The other call legs are abandoned. 

The members of an FA group are described by a list of termination addresses. 

4.2 Description 
4.2.1 General description 

FA may be used for either a single user or multiple users. The difference between the two is in determining when the 
FA group is busy. In the single user case, the group is considered to be busy when one of the members is considered to 
be busy. In the multiple user case, the group is considered to be busy when all of the accessible members are considered 
to be busy. A member is considered to be busy when it cannot accept the presentation of another call. 

The FA pilot identity may have features to manage incoming calls (e.g.. Incoming Communications Barring). These 
features should take precedence over the corresponding features of individual members as described in subclause 4.6. 

If an FA pilot identity is an FA member Identity, the FA member loses his or her individual incoming call features. In 
this case, the FA member's incoming call features are superseded by the incoming call features of the FA pilot identity. 

If an FA pilot identity is not an FA member Identity, the features of the FA pilot identity may be changed only through 
user or service provider configuration. 

FA does not affect the ability of an FA member to originate calls. FA may affect the ability of an FA member to receive 
calls. 

If an FA member has only a single identity that is the same as the FA pilot identity, the FA member may not receive 
calls except through the FA pilot identity. 

If an FA member has an identity different than the FA pilot identity, the FA member may receive calls as an individual 
as well as calls through the FA pilot identity. Such an FA member may use revertive calling (i.e., a call to itself) for 
other purposes, such as retrieval of voice mail. 
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4.3 Operational requirements 



4.3.1 



Provision/withdrawal 



The FA service may be provided after prior arrangement with the service provider. The establishment of the initial 
constituency (membership) of the FA group, along with additions to or subtractions from the set of group members, is 
performed by the service provider. 

The FA service may be withdrawn at the subscriber's request or for administrative reasons. Withdrawal of the FA 
service means dissolution of the FA group and results in calls to the Pilot Identity being treated as calls to a vacant 
identity. Withdrawal of the FA service is performed by the service provider. 

As determined by service provider provisioning, the FA group may have the following subscription options, as 
summarized in table 4.3.1-1. 

Table 4.3.1-1 : FA group subscription options 



Subscription option values 


Values 


Type 


- Single User. The FA group is considered to be busy 
wtien any member of tine group is considered to be 
busy. 

- IVIultiple Users. Ttie FA group is considered to be 
busy wtien all accessible members of the group are 
considered to be busy. 



As determined by service provider provisioning, the FA member may have the following subscription options, as 
summarized in table 4.3.1-2. 

Table 4.3.1-2: FA member subscription options 



Subscription option values 


Values 


Membership 


- Demand. An FA member is authorized to activate or 
deactivate his or her membership in the FA group(s). 

- Permanent. An FA member is always a member of 
his or her registered FA group(s). 



If an FA group is of type 'demand activation', any configured FA member is able to, by means of user configuration, 
change their status in the FA group from 'active' to 'inactive' or from 'inactive' to 'active'. The FA member status options 
are summarized in table 4.3.1-3. 

Table 4.3.1-3: FA member status options 



Subscription option values 


Values 


Status 


- Active. An FA member is eligible to be alerted when 
a call is placed to the Pilot Identity. 

- Inactive. An FA member is not eligible to be alerted 
when a call is placed to the Pilot Identity.. 



Available user configuration actions for FA are described in subclause 4.5.2. 

For user configuration of FA, the SIP-based user configuration capability as described in 3GPP TS 24.238 [4] or the Ut 
interface as described in 3GPP TS 24.623 [6] could be used. More detail is described in subclause 4.8. 

Other possibilities for provisioning could be used too, like web based provisioning or pre-provisioning by the operator. 

4.3.2 Requirements on the originating network side 

There are no requirements on the originating network side for FA. FA is a terminating network side service. 
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4.3.3 Requirements on the terminating networl< side 

The public user identity that represents the pilot identity of the FA group has an always-registered presence on the IM 
CN subsystem. The pilot identity is associated with a typical IM CN subsystem user service profile. 

4.4 Syntax requirements 

There are no special SIP syntax requirements for the FA service. The FA service is invoked when an IM CN subsystem 
session is terminated to the pilot identity of an FA group. 

4.5 Signalling procedures 

4.5.1 General 

For user configuration of the FA service by a member of the FA group, either the Ut interface or the SIP -based user 
configuration capability (as specified by 3GPP TS 24.238 [4]) should be used. 

The enhancements to the XML schema for use over the Ut interface are described in subclause 4.8. 

NOTE: Other possibilities for user configuration, such as web-based provisioning, are outside the scope of the 
present document. 

4.5.2 Activation/deactivation 

4.5.2.1 General 

The FA service is activated at provisioning and deactivated at withdrawal. 

For an FA group that is of type 'demand activation', activation or deactivation of membership is accomplished by means 
of user configuration and may be achieved by using either: 

the Ut interface using XCAP as enabling protocol as described in 3GPP TS 24.623 [6]; or 

SIP based user configuration as described in 3GPP TS 24.238 [3]; 

NOTE: Other possibilities for user configuration, such as web-based provisioning or pre-provisioning by the 
operator are outside the scope of the present document, but are not precluded. 

The enhancements to the XML schema for use over the Ut interface are described in subclause 4.9. 

Editor's Note: How the UE selects the service configuration mechanism is FFS. Whether simultaneous usage of 
different configuration mechanisms is allowed is FFS. It should be stated that SIP based user 
configuration may have limitations in service configuration compared to Ut interface mechanism. 

4.5.2.2 Demand member activation of a subscriber's default FA group(s) 

For an FA group that is of type 'demand activation', an FA member may activate his or her membership in the 
subscriber's default FA group(s) by specifying the FA membership activation feature code: 

An example of the code is: *FC 

If the activation is accepted, the system shall indicate success with feature confirmation treatment. 

4.5.2.3 Demand member activation of a specified FA group 

For an FA group that is of type 'demand activation', an FA member may activate his or her membership in a particular 
FA group by specifying the FA membership activation feature code and a specific FA pilot identity: 

An example of the code is: *FC + FA pilot identity 
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If the activation is accepted, the system shall indicate success with feature confirmation treatment. 

4.5.2.4 Demand member deactivation of a subscriber's default FA group(s) 

For an FA group that is of type 'demand activation', an FA member may deactivate his or her membership in the 
subscriber's default FA group(s) by specifying the FA membership deactivation feature code: 

An example of the code is: *FCO 

If the deactivation is accepted, the system shall indicate success with feature confirmation treatment. 

4.5.2.5 Demand member deactivation of a specified FA group 

For an FA group that is of type 'demand activation', an FA member may deactivate his or her membership in a particular 
FA group by specifying the FA membership deactivation feature code and a specific FA pilot identity: 

An example of the code is: *FCO + FA pilot identity 

If the deactivation is accepted, the system shall indicate success with feature confirmation treatment. 

4.5.3 Registration/erasure 

Individual members of the FA group may be added or deleted at any time by the service provider. 

4.5.4 Interrogation 

4.5.4.1 General 

For interrogation, the mechanisms described in subclause 4.5.1 should be used. 

4.5.4.2 Interrogation using Ut interface 

The enhancements to the XML schema for use over the Ut interface are described in subclause 4.9. 

4.5.4.3 Interrogation using the SIP-based user configuration 

For an FA group that is of type 'demand activation', an FA member may interrogate his or her membership status in the 
subscriber's default FA group(s) by specifying the FA membership interrogation feature code: 

An example of the code is: *FC1 

For an FA group that is of type 'demand activation', an FA member may interrogate his or her membership status in a 
particular FA group by specifying the FA membership interrogation feature code and a specific FA pilot identity: 

An example of the code is: *FC1 + FA pilot identity 

NOTE 1 : The response to such interrogation is not specified for the FA service. AS interactions with the MRF over 
the CR reference point or a solution based on IVR can be used as a possible interrogation response. 

4.5.5 Invocation and operation 

4.5.5.1 Actions at the AS serving the originating UE 

There are no procedures at the originating AS relevant to the FA service. 

4.5.5.2 Actions at the AS serving the pilot identity 

Procedures specified in 3GPP TS 24.229 [5] for an AS acting as a routing B2BUA shall apply, with the additions 
described in this subclause. 
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Upon receiving an incoming SIP INVITE request destined to the pilot identity, the AS shall send the SIP INVITE 
request to all the member identities within the FA group. 

Upon receiving a SIP 200 (OK) response to the SIP INVITE request from a member UE, the AS shall: 

send SIP CANCEL request to cancel the SIP INVITE request to all member UEs that have not sent a final 
response; and 

send the SIP 200 (OK) response for the SIP INVITE request to the originating UE. 

For a single-user FA group, if the AS receives SIP 486 (Busy Here) response from any of the member UEs before 
receiving SIP 2xx responses, the AS shall: 

send SIP CANCEL request to cancel the SIP INVITE request to all member UEs that have not sent a final 
response; and 

send the SIP 486 (Busy Here) response to the originating UE. 

For a multiple-user FA group, if the AS receives SIP 486 (Busy Here) responses from each (all) of the member UEs, the 
AS shall send a SIP 486 (Busy Here) response to the originating UE. 

4.6 Interaction with other services 

4.6.1 Communication session Hold (HOLD) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.2 Terminating Identification Presentation (TIP) 

If the FA pilot identity did not apply TIR, the termination identification is the FA pilot identity. 

4.6.3 Terminating Identification Restriction (TIR) 

If the FA pilot identity has TIR activated, the termination identification is not presented. 

4.6.4 Originating Identification Presentation (OIP) 

If the FA pilot identity has OIP activated, incoming calls to the FA pilot identity apply OIP to the members of the FA 
group. 

4.6.5 Originating Identification Restriction (OIR) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.6 Conference (CONF) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.7 Communication Diversion services (CDIV) 
4.6.7.1 Communication Forwarding Unconditional (CFU) 

CFU is applicable to FA. If CFU is active for the Pilot Identity, the FA AS shall perform the procedures related to CFU 
prior to executing the FA service. 

CFU of the FA Pilot Identity takes precedence over CFU of the individual FA members. That is, if both the FA Pilot 
Identity and an FA member have CFU active, CFU treatment is determined by the Pilot Identity's service profile. 

A forwarded communication can invoke the FA supplementary service. 
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Editor's note: The case when a member has CPU and the pilot identity does not is FFS. Also the case when multiple 
members have CFU activated must be considered. 

4.6.7.2 Communication Forwarding Busy (CFB) 

CFB of the FA Pilot Identity shall apply to calls to the Pilot Identity when CFB is active and the FA group is considered 
to be busy. CFB takes precedence over FA. If CFB is active for the Pilot Identity, the FA AS shall perform the 
procedures related to CFB prior to executing the FA service. 

CFB of the FA Pilot Identity takes precedence over CFB of the individual FA members. That is, if both the FA Pilot 
Identity and an FA member have CFB active, CFB treatment is determined by the Pilot Identity's service profile. 

If while a call to the Pilot Identity remains in progress, and the FA group has not yet been considered busy, yet an 
individual call leg (i.e. FA member) is reported 'busy' and its associated service profile does have CFB active, the CFB 
service should be invoked on behalf of that member. 

A forwarded communication can invoke the FA supplementary service. 

4.6.7.3 Communication Forwarding No Reply (CFNR) 

CFNR of the FA Pilot Identity shall apply to calls to the Pilot Identity when CFNR is active and the call is not or cannot 
be answered for reason that there is no reply from any of the FA members. CFNR takes precedence over FA. If CFNR 
is active for the Pilot Identity, the FA AS shall perform the procedures related to CFNR prior to executing the FA 
service. 

CFNR of the FA Pilot Identity takes precedence over CFNR of the individual FA members. That is, if both the FA Pilot 
Identity and an FA member have CFNR active, CFNR treatment is determined by the Pilot Identity's service profile. 

If while a call to the Pilot Identity remains in progress, and the criteria to invoke the CFNR service is met with respect 
to an individual call leg (i.e. FA member), the CFNR service should be invoked on behalf of that member. 

If FA group is of type "Multiple Users", and not all users return a SIP 486 (Busy Here) response, and the other FA 
members within the FA group do not reply or are not logged in, then CFNR of the FA Pilot Identity shall apply. 

A forwarded communication can invoke the FA supplementary service. 

4.6.7.4 Communication Forwarding Not Reachable (CFNRc) 

CFNRc of the FA Pilot Identity shall apply to calls to the Pilot Identity when CFNRc is active and the call is not or 
cannot be answered for reason that none of the FA members is reachable. CFNRc takes precedence over FA. If CFNRc 
is active for the Pilot Identity, the FA AS shall perform the procedures related to CFNRc prior to executing the FA 
service. 

CFNRc of the FA Pilot Identity takes precedence over CFNRc of the individual FA members. That is, if both the FA 
Pilot Identity and an FA member have CFNRc active, CFNRc treatment is determined by the Pilot Identity's service 
profile. 

If while a call to the Pilot Identity remains in progress, and the criteria to invoke the CFNRc service is met with respect 
to an individual call leg (i.e. FA member), the CFNRc service should be invoked on behalf of that member. 

A forwarded communication can invoke the FA supplementary service. 

4.6.7.5 Communication Deflection (CD) 

No impact, i.e. neither service shall affect the operation of the other service. CD does not apply to the Pilot Identity. 
A forwarded communication can invoke the FA supplementary service. 

4.6.7.6 Communication Forwarding on Not Logged-ln (CFNL) 

CFNL of the FA Pilot Identity shall apply to calls to the Pilot Identity when CFNL is active and the call is not or cannot 
be answered for reason that none of the FA members is logged-in. CFNL takes precedence over FA. If CFNL is active 
for the Pilot Identity, the FA AS shall perform the procedures related to CFNL prior to executing the FA service. 
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CFNL of the FA Pilot Identity takes precedence over CFNL of the individual FA members. That is, if both the FA Pilot 
Identity and an FA member have CFNL active, CFNL treatment is determined by the Pilot Identity's service profile. 

If while a call to the Pilot Identity remains in progress, and the criteria to invoke the CFNL service is met with respect 
to an individual call leg (i.e. FA member), the CFNL service should be invoked on behalf of that member. 

A forwarded communication can invoke the FA supplementary service. 

4.6.8 Message Waiting Indication (MWI) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.6.9 Communication Barring (CB) 

Incoming Communications Barring (ICB) and Anonymous Call Rejection (ACR) of the FA pilot identity take 
precedence over FA. That is, calls to the FA pilot identity with ICB/ACR active are checked for the ICB/ACR first. If 
the call is not allowed by ICB/ACR, the call is refused. If the call is accepted by ICB/ACR, the call is given FA 
treatment. 

ICB/ACR may apply for individual FA members for calls to the FA pilot identity. FA calls destined to a particular FA 
member may, after screening against the FA pilot identity, be screened against a FA member's screening list to prevent 
the unintended delivery of a call to a member. If the second screening fails, the member should be considered 
inaccessible and the call should be attempted to be delivered to another member. The screening of all the members 
pertaining to an FA group shall be done so that all members are alerted at nearly the same time. 

4.6.1 Explicit Communication Transfer (ECT) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.7 Parameter values (timers) 

No timers for FA service are defined. 

4.8 Service configuration 
4.8.1 General 

Flexible Alerting documents are sub-trees of the simservs XML document specified in 3GPP TS 24.623 [6]. As such. 
Originating Identity documents use the XCAP application usage in 3GPP TS 24.623 [6]. 

Data semantics: The semantics of the Flexible Alerting XML configuration document is specified in subclause 4.8.2. 

XML schema: Implementations in compliance with the present document shall implement the XML schema that 
minimally includes the XML Schema defined in subclause 4.8.3 and the simservs XML schema specified in 
subclause 6.3 of 3GPP TS 24.623 [6]. 

An instance of an Flexible Alerting document is shown: 

<?xml version="l . 0" encoding="UTF-8" ?> 

< simservs xmlns="http : //uri . etsi .org/ngn/params/xml/simservs/xcap" 
xmlns :xsi="http : //www.w3 . org/2 00 1/XMLSchema- instance" > 
< flexible -alerting- default active="true"/> 

<f lexible-alerting-specif ic active="true" > 

<pilot-identity>sip :pilot_identity@homel .net</pilot-identity> 
</f lexible-alerting-specif ic> 
</simservs> 
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4.8.2 Data semantics 

For an FA group that is of type 'demand activation': 

an FA member man activate or deactivate their membership from their default FA groups using the active 
attribute of the <flexible-alerting-default> service element. 

an FA member may activate or deactivate their membership from a particular FA group identified by its Pilot 
Identity using the active attribute of the <flexible-alerting-specific> service element. The Pilot Identity of the FA 
group is configured in the <identity> element as a URL 

4.8.3 XML schema 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema targetNamespace=" http : //uri . etsi .org/ngn/params/xml/simservs/xcap " 

xmlns : ss=" http : //uri . etsi . org/ngn/params/xml/simservs/xcap " 

xmlns :xs=" http : //www. w3 . org/2 001/XMLSchema " elementFormDef ault="qualif ied" 

attributeFormDefault=" unqualified" > 

<xs : element name=" flexible -alerting- default" type="ss : simservType" 
substitutionGroup="ss : absService" > 
<xs : annotation> 

<xs :documentation>Flexible Alerting Default Groups Membership 
</xs : documentation> 
</xs : annotation> 
</xs : element > 

<xs : element name=" flexible -alerting- specific" substitutionGroup="ss : absService" > 
<xs : annotation> 

<xs :documentation>Flexible Alerting Specific Groups Membership 
</xs : documentation> 
</xs : annotation> 
<xs : complexType> 

<xs : complexContent> 

<xs : extension base="ss : simservType" > 
<xs : sequence> 

<xs: element name=" identity" type="xs : anyURI" minOccurs="0" 
maxOccur s = " unbounded " / > 

<xs : any namespace="##other" minOccurs=" 0" maxOccurs="unbounded" 
processContents="lax"/> 
</xs : sequence> 

<xs : anyAttribute namespace="##other"/> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : element > 
</xs : schema> 
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Annex A (informative): 
Signalling flows 



A.1 Scope of signalling flows 



This annex gives examples of signalling flows for the FA service within the IP Multimedia (IM) Core Network (CN) 
subsystem based on the Session Initiation Protocol (SIP). 



A.2 Introduction 

A. 3 FA model signalling flow 
A.3.1 Introduction 

The following flow shows the establishment of a session between UE#1 and UE#2. The following flow is included: 

subclause A. 3. 2 shows FA, when UE#1 and UE#2 have resources available and UE#3 does not have required 
resources available. 

A.3.2 FA when UE#1 and UE#2 have resources available and 
UE#3 does not have required resources available 

Figure A.3.2-1 and figure A.3.2-2 show the FA service invoked when UE#1 sends an INVITE request to the Pilot 
Identity. UE#2 and UE#3 have registered public user identities that are included in the FA group. In this example, UE#I 
and UE#2 have resources available prior to session initiation, whereas UE#3 does not have the required resources 
available before it receives the initial INVITE request. This example assumes that all the UEs involved in this session 
support the IMS Multimedia Telephony Communication Service. 
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I — 7. PRACK|Di) - 
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User Answers 



25. 200 (OK)|D3| 
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Resources 
not available 



Resources available 



Figure A.3.2-1 : FA, UE#3 does not have required resources available 



£75/ 



3GPP TS 24.239 version 8.1.0 Release 8 



17 



ETSI TS 124 239 V8.1.0 (2009-03) 



UE#1 



S-CSCF 



- 36. 200 (OK)(SDP_A2,D2) 
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32. 487 (Request 
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- 33. ACK(Di) — 



FA AS 



35. 200 (OK)(SDP_A2,D2) - 



38. ACK(D2) ► 

39. ACK(D3) 



31. 487 (Request 
Terminated)(Di) 



34. ACK(Di) 



40. ACK(D3) 




Figure A.3.2-2: FA, UE#3 does not have required resources available 

1 INVITE request (UE#1 to S-CSCF) see example in table A.3.2-1 

UE#1 sends a SIP INVITE request to the intermediate IM CN subsystem. 
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Table A.3.2-1 : INVITE request (UE#1 to FA-AS) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info : IEEE-802 . 11a 

P- Preferred- Service : urn: urn- 7 : 3gpp- service . ims . icsi .mmtel 

Accept -Contact : * ; +g. 3gpp . icsi -ref="urn%3Aurn-7%3gpp- service . ims .icsi .mmtel" 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 
port-c=8642; port-s=7531 

Contact : <sip :userl_publicl®homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91e6bf6>;+g. 3gpp . icsi-ref ="urn%3Aurn- 7% 3gpp- service. ims .icsi .mmtel" 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Accept : application/sdp, . application/3gpp-ims+xml 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 6666 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 6666 :: aaa: bbb: ccc : ddd 

t=0 

m=video 34 RTP/AVP 98 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

a=tcap:l RTP/AVPF 

a=pcfg:l t=l 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



Request-URI: The request URI is set to the Pilot Identity of the FA group. 

Supported: The UE indicates support for preconditions, reliable provisional responses, gruu and the 199 

provisional response. 

SDP: The SDP offer (SDP_0) contains a set of codecs supported by UE#1 and desired by the calling 

user for this session. The local preconditions are indicated as fulfilled. 

2 INVITE request (S-CSCF to FA-AS) 

The S-CSCF forwards the SIP INVITE request to the FA-AS. 

3-4 INVITE request (FA-AS to UE#3) 

The Pilot Identity included in the Request-URI in the received INVITE request is mapped to the public user 
identities of the individual FA members in the FA group. The FA-AS forwards the INVITE request to the 
individual FA members in the FA group. The FA-AS forwards the INVITE request to UE#3, with the Request- 
URI set the public user identity which is an identity included in the FA group and registered from UE#3. 



£75/ 



3GPP TS 24.239 version 8.1 .0 Release 8 1 9 ETSI TS 1 24 239 V8.1 .0 (2009-03) 

5-6 180 (Ringing) provisional response (UE#3 to FA-AS) see example in table A.3.2-2 

The called party is alerted. UE#3 sends a reliable SIP 180 (Ringing) provisional response for the INVITE request 
to the FA-AS. 

Table A.3.4-2: 180 (Ringing) response (UE#3 to FA-AS) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf2 .visited2 .net :5088;comp=sigcomp;branch=z9hG4bK361k21.1, SIP/2. 0/UDP 

sc£3cf 2 .home2 .net ;branch=z9hG4bK764XC12 .1, SIP/2 . 0/UDP 

faas.home2 .net ;branch=z9hG4bK764Q3 2 .1, SIP/2 .0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764zB7 . 1 , SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bKB71yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK3 3 2b2 3 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 135 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Record- Route : <sip ipcscf 2 . visited2 .net : 5 088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net ; lr>, 

<sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net ; lr> 
From: 

To: <tel: +1-212 -555- 10 01>;tag=6322 
Call-ID: 
Cseq: 

Require: lOOrel, precondition 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
RSeq: 9021 

Contact : <sip :user3_publicl@visitedl .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91er2d2>,• +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 6666 : : eee : f f f : aaa : bbb 

s = - 

c = IN IP6 6666 : :eee:fff :aaa:bbb 

t = 

m=video 34 RTP/AVPF 98 

a=acfg:l t=l 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVPF 97 96 

a=acfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes 



SDP: The SDP answer (SDP_A1) contains a set of codecs to be used for the session. The local 

preconditions are indicated as fulfilled. 

7-8 PRACK request (FA-AS to UE#3) 

FA-AS sends a SIP PRACK request, which acknowledges the SIP 180 (Ringing) provisional response, to 

UE##3. 

9-10 200 (OK) response to PRACK (UE#3 to FA-AS) 

UE#3 sends a SIP 200 (OK) response for the SIP PRACK request to FA-AS. 
11-12 180 (Ringing) provisional response (FA-AS to UE#1) 

The FA-AS sends a reliable SIP 180 (Ringing) provisional response to UE#1. 
An early dialog (D2) is established between UE#1 and the FA-AS. 
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13-14 PRACK request (UE#1 to FA-AS) 

UE#1 sends a SIP PRACK request, which acknowledges the SIP 180 (Ringing) provisional response, to the FA- 
AS. 

15-16 200 (OK) response to PRACK (FA-AS to UE#1) 

The FA-AS sends a SIP 200 (OK) response for the SIP PRACK request to UE#1. 

17-18 INVITE request (FA-AS to UE#2) 

The Pilot Identity included in the Request-URI in the received INVITE request is mapped to the public user 
identities of the individual FA members in the FA group. The FA-AS forwards the INVITE request to the 
individual FA members in the FA group. In parallel to forwarding the request to UE #3 (see step 3), the FA-AS 
forwards the request to UE#2, with the Request-URI set the public user identity which is an identity included in 
the FA group and registered from UE#2. 

19-20 180 (Ringing) provisional response (UE#2 to FA-AS) see example in table A.3.2-2 

The called party is alerted. UE#2 sends a reliable SIP 180 (Ringing) provisional response for the INVITE request 
to the FA-AS. 

Table A.3.4-3: 180 (Ringing) response (UE#2 to FA-AS) 



SIP/2.0 180 Ringing 

Via: SIP/2. 0/UDP pcscf2 .visited2 .net :5088;comp=sigcomp;branch=z9hG4bK3Slk21.1, SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764XC12 .1, SIP/2 . 0/UDP 

faas.home2 .net ;branch=z9hG4bK764Q3 2 .1, SIP/2 .0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764zB7 . 1 , SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bKB71yl2 .1, SIP/2 .0/UDP 

scscf 1 .homel .net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscf 1 . visitedl .net ;branch=z9hG4bK24 0f 34 .1, SIP/2 . 0/UDP 

[5555 : :aaa:bbb: ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip : pcscf 2 . visited2 .net : 5088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net; lr>, 

<sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net ; lr> 
From: 

To: <tel:+l-212-555-10 02>;tag=4114 
Call-ID: 
Cseq: 

Require: lOOrel, precondition 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
RSeq: 7187 

Contact : <sip :user2_publicl@visitedl .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a76 5- 
00a0c91ewxyz>,• +g. 3gpp. icsi-ref ="urn%3Aurn- 7 %3gpp- service . ims . icsi .mmtel" 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 6666 :: eee : fff : aaa : ccc 

s = - 

c = IN IP6 6666 :: eee : fff : aaa : ccc 

t = 

m=video 34 RTP/AVPF 98 

a=acfg:l t=l 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVPF 97 96 

a=acfg:l t=l 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes 
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SDP: The SDP answer (SDP_A2) contains a set of codecs to be used for the session. The local 

preconditions are indicated as fulfilled. 

21-22 PRACK request (FA-AS to UE#2) 

FA- AS sends a SIP PRACK request, which acknowledges the SIP 180 (Ringing) provisional response, to UE#2. 
23-24 200 (OK) response to PRACK (UE#2 to FA-AS) 

UE#2 sends a SIP 200 (OK) response for the SIP PRACK request to FA-AS. 

25-26 200 (OK) response to INVITE (UE#2 to FA-AS) 

The called party answers the call. UE#2 sends a SIP 200 (OK) final response for the SIP INVITE request to the 
FA-AS. 

27-28 CANCEL request (FA-AS to UE#3) 

FA-AS sends a SIP CANCEL request, to cancel early dialog Dl, to UE#3. 
29-30 200 (OK) response to CANCEL (UE#3 to FA-AS) 

UE#3 sends a SIP 200 (OK) response for the SIP PRACK request to FA-AS. 
31-32 487 (Request Terminated) (UE#3 to FA-AS) 

UE#3 sends a SIP 487 (Request Terminated), to cancel early dialog Dl, to FA-AS. 
33-34 ACK request to CANCEL (FA-AS to FA-UE#3) 

FA-AS sends a SIP ACK request, which acknowledges the 200 (OK) to CANCEL, to UE#3. 

35-36 200 (OK) response to INVITE (FA-AS to UE#1) 

In parallel to sending the CANCEL request to UE#3 (see step 27), the FA-AS sends a SIP 200 (OK) response to 
UE#L The response contains SDP answer (SDP_A2). 

37-38 ACK request (UE#1 to FA-AS) 

UE#1 sends a SIP ACK request, which acknowledges the SIP 200 (OK) final response, to FA-AS. 
39-40 ACK request (FA-AS to UE#2) 

FA-AS sends a SIP ACK request, which acknowledges the SIP 200 (OK) final response, to UE#2. 
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Annex B (informative): 
Example of filter criteria 



This annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria 
evaluation. 

When the initial request matches the conditions of the next unexecuted IFC rule for the served user which points to the 
FA service and the, the communication is forwarded to the AS. 

An example of an Initial Filter Criteria (IFC) Trigger Point configurations under the assumption that the FA service is a 
standalone service that can be invoked by a very specific triggerpoint active at the destination S-CSCF: 

- (Method='TNVITE" AND Header="Request-URI"). 

NOTE 1: The coding of the Initial Filter Criteria is described in 3GPP TS 29.228 [7]. 
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